Collection of Tools & Utilities/Collection of Tools and Utilities.iso/comm/tskerm25.zip/TSKERM.POS

Text File | 1994-02-12 | 26KB | 567 lines

===========================================================================
I have collected here with the kind permission of the authors some
interestings posting and email concerning MsKermit and related file
transfer problems and principles.  My sincere thanks to Russ, Kenneth,
James, Kevin, Joe, Christine, et al.
   All the best, Timo
===========================================================================

From [e-mail] Sun Nov 12 19:08:07 1989
Return-Path: <[e-mail]>
From: Russell Herman <[e-mail]>
To: [e-mail]
Subject: Re: Kermit file transfers made easy
Message-Id: <[e-mail]>
Date:     Sun, 12 Nov 89 12:05:53 EST

I may have the solution to your zmodem problems!  I have a similar situation
with a pair of back-to-back async dataswitches between me sitting here at home
and the SUN 3/180 running SUNOS3.5 at work.  After struggling and some hints
from Forsberg, I got everything working by invoking sz at the host with the
inclusion of '-l 1024'.  This forces zmodem to use a dumber version of its
protocol that ACKs each packet before sending the next.  The problem I
encountered was essentially flow control.  By the time my XOFF drifted
upstream, my intermediaries were filled up with packets I wasn't ready to
swallow.  Everything went totally out of sync by that point.  Some
configuration peculiarities make it unnecessary for me to worry about
this when I'm uploading from the PC, although I guess the problem could
really cut both ways.

There is a slight performance hit.  Over a 2400 baud modem I get about
210 cps instead of 220, and over a 9600 direct wire 800 cps vs 900
(just done as an experiment, there's no need to use -l over a wire
unless perhaps a PC can't keep up in some weird fashion).

I did use kermit before figuring out this solution.  But why dig with a
teaspoon when you can dig with a shovel?

Russ Herman
INTERNET: [e-mail]  UUCP: ..uunet!utai!me!rwh


Article 2645 of comp.binaries.ibm.pc.d:
>From: [e-mail] (Usenet file owner)
Newsgroups: comp.binaries.ibm.pc.d,comp.sys.ibm.pc
Subject: Re: Kermit file transfers made easy
Keywords: kermit, scripts
Message-ID: <[e-mail]>
Date: 12 Nov 89 04:29:40 GMT
References: <[e-mail]>
Reply-To: [e-mail] (Kenneth J. Hendrickson)
Organization: Michigan State University
Lines: 19

Kermit uses only 7-bit ascii characters for its file tranfer protocol.
If you send files with 8-bit characters (binary files like .EXE, .ARC,
.ZOO, .ZIP, etc.), Kermit uses quoting, where a special character is
used to flag a byte with the eighth bit set.  If you send binary files
this way, it effectively doubles the size of the file.

In order to go faster, I recommend using arc -i on your Unix system,
then uuencoding the file.  Uuencode makes the file about 33% larger, but
arc can achieve compression ratios of 50%+.  Transfer the file, and then
perform the reverse process on your pc.  The -i option for arc does the
\n MSDOS <-> Unix translation.  PKXARC can be made compatible with arc
by using the -oct switch.

This helps on text files a little bit, and on binary files a whole
bunch!

In the rare case that original ideas   Kenneth J. Hendrickson    N8DGN
are found here, I am responsible.      Owen W328, E. Lansing, MI 48825
Internet: [e-mail]   UUCP: ...!uunet!frith!hendrick


Article 2648 of comp.binaries.ibm.pc.d:
>From: [e-mail] (James Webster Birdsall)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: Kermit file transfers made easy
Keywords: kermit, scripts
Message-ID: <[e-mail]>
Date: 12 Nov 89 18:41:45 GMT
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (James Webster Birdsall)
Organization: Princeton University, NJ
Lines: 28

In article <[e-mail]> [e-mail] (Kenneth J. Hendrickson)
writes:
>Kermit uses only 7-bit ascii characters for its file tranfer protocol.
>If you send files with 8-bit characters (binary files like .EXE, .ARC,
>.ZOO, .ZIP, etc.), Kermit uses quoting, where a special character is
>used to flag a byte with the eighth bit set.  If you send binary files
>this way, it effectively doubles the size of the file.

   Correction: Kermit uses the full width of whatever communication line
it has available. On a 7-bit line, it can send text straight and
binaries by quoting (which drops the speed by a lot -- it's usually
faster to uuencode and download as text). On an 8-bit line, it can
send binaries straight. [Your mileage may vary. I'm using MS-Kermit
(in the various versions since 2.29) and C-Kermit (version whatever)
on assorted UNIX boxes.]
   When I did CPS measurements (CPS of the original file, not the
uuencoded version, if appropriate), I found that 8-bit was the fastest
for binaries, followed by 7-bit text of uuencoded file, followed by
7-bit quoted binary. Boosting the packet size to the max of 1000 helped
throughput a lot as well (if you've got dirty lines, this may not be
true -- around here, the lines are very clean and I get maybe one resend
every other month).

--
James W. Birdsall  [e-mail]  [e-mail]
   ...allegra!princeton!phoenix!jwbirdsa   Compu$erve: 71261,1731
"For it is the doom of men that they forget." -- Merlin


Article 2652 of comp.binaries.ibm.pc.d:
>From: [e-mail]
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: Kermit file transfers made easy
Message-ID: <[e-mail]>
Date: 12 Nov 89 19:02:00 GMT
References: <[e-mail]>
Lines: 23

Jim Birdsall is right.  Look at the following examples.  Consider first that
a binary files has statistically 50% bytes with leading zeroes and 50%
bytes with leading ones (varies from file to file, but statistaclly
right).  That means that transferring a binary file on a 7 bit ASCII
connection will cause 50% of the bytes to be quoted.  Equivalent of
increasing the file size by 50%.  UUENCODEing is a 3 byte-to-4 byte encoding
of your binary text.  It increases your file size by 33.3% (regardless of
the percentage of bytes beginning with 1's or 0's!).  Obviously transferring
a binary file over an 8-bit line has no penalty (0% file growth!).

============================================================================
Kevin J. Cummings                       Prime Computer Inc.
20 Briarwood Road                       500 Old Connecticut Path
Framingham, Mass.                       Framingham, Mass.

InterNet:  [e-mail]
CSNet:     [e-mail]
UUCP:      {uunet, csnet-relay}!S55.Prime.COM!CUMMINGS

Std. Disclaimer: "Mr. McKittrick, after careful consideration, I've come
                  to the conclusion that your new defense system SUCKS..."
============================================================================


Article 2727 of comp.binaries.ibm.pc.d:
>From: [e-mail] (Joe Doupnik)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Kermit file transfers, a remark.
Message-ID: <[e-mail]>
Date: 18 Nov 89 22:23:38 GMT
Lines: 17

        There is a natural misconception regarding Kermit and 7 or 8 bit file
transfers. Kermit uses 8 bit transfers if parity is none, otherwise it uses
7 bits and encoding for the eighth bit. Even under Unix C Kermit runs the
communications line in full 8-bit mode during file transfers, if at all
possible, even though the conversational parts use the normal Unix parity.
Each Kermit determines the local parity situation and the width of the
transfer is negotiated between them at file transfer time.
        I might add in passing that the Kermit protocol permits run length
encoding naturally, most Kermits support it, to help compress many files.
Not the same as the full blown archive compression schemes. If a communications
channel is 7 bits wide then archive style compression of text files may yield
a slower transmission than the original text files because of escaping all
the new eighth bits. The